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(54) Method for key distribution and verification in a key management system 

(57) A method of token verification in a Key Man- 
agement System (10) provides a logical device identifier 
and a master key created in a logical security domain to 
a transaction evidencing device, such as a digital post- 
age meter (36). The method creates a master key 
record in a key verification box, securely stores the mas- 
ter key record in a Key Management System archive 
(25), and produces in the transaction evidencing device 
(36) evidence in the logical security domain of transac- 
tion information integrity. The method inputs the evi- 
dence of the transaction information integrity to a token 
verification box (21). and inputs in the token verification 
box the master key record from the Key Management 
System archive (25). The method determines in the 
token verification box that the master key is valid in log- 
ical security domain, uses in the token verification box 
(21) the master key to verify the evidence of transaction 
information integrity, and outputs from the token verifi- 
cation box (21) an indication of the result of the verifica- 
tion of the evidence of transaction information integrity. 
The master key record includes the logical device iden- 
tifier, the master key and a digital signature associating 
the logical device identifier and the master key. The 
method checks the digital signature to verify the associ- 
ation of the logical device identifier and the master key 
within the logical security domain. 
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Description 

Held of the Invention 

The present invention relates generally to a system 
for cryptographic key management and, more particu- 
larly, to a system for key management of cryptographic 
keys distributed to postage meters. 

Related Applications 

The present application is related to three Euro- 
pean applications corresponding to U.S. Applications 
Serial Nos. 08/415,824, 08/414,897 and 08/414,563 
filed concurrently herewith and assigned to the 
assignee of the present invention. The disclosures of 
these European applications are hereby incorporated 
herein by reference. 

Digital printing technology has enabled mailers to 
implement digital, i.e. bit map addressable, printing in a 
convenient manner. It has been found to be desirable to 
use such techniques for the purpose of evidencing pay- 
ment of postage. Technological advances in digital 
printing technology has made it possible to print post- 
age indicia that is unique for each mailpiece. A compu- 
ter driven printer can print, for example, a postal indicia 
in a desired location on the face of a mailpiece. The indi- 
cia is unique because it includes information relating 
directly to the mailpiece, for example, postage value, 
date, piece count and/or origin postal code. 

From a Post Office's perspective, it will be appreci- 
ated that the digital printing and scanning technology 
make it fairly easy to counterfeit a postal value bearing 
indicia since any suitable computer and printer may be 
used to generate multiple copies of an image. 

In order to validate a mailpiece, that is to ensure 
that accounting for the postage amount printed on a 
mailpiece has been properly done, it is known that one 
may include as part of the franking an encrypted 
number such that, for instance, the value of the franking 
may be determined from the encryption to learn 
whether the value as printed on the mailpiece is correct. 
See, for example, U.S. Patent Nos. 4,757,537 and 
4,775,246 to Edelmann et al., as well as U.S. Patent No. 
4,649,266 to Eckert. It is also known to authenticate a 
mailpiece by including the address as a further part of 
the encryption as described in U.S. Patent No. 
4,725,718 to Sansone et al. and U.S. Patent No. 
4,743,747 to Fougere et al. 

U.S. Patent No. 5.170.044 to Pastor describes a 
method and apparatus for the representation of binary 
data in the form of an indicia comprising a binary array 
of pixels. The actual arrays of pixels are scanned in 
order to identify the provider of the mailpiece and to 
recover other encrypted plain text information. U.S. Pat- 
ent No. 5,142,577 to Pastor describes various alterna- 
tives to the DES encoding for encrypting a message 
and for comparing the decrypted postal information to 
the plain text information on the mailpiece. 



U.S. Patent No. 5,390.251 to Pastor et al. describes 
a system for controlling the validity of printing of indicia 
on mailpieces from a potentially large number of users 
of postage meters including apparatus disposed in each 

5 meter tor generating a code and for printing the code on 
each mailpiece. The code is an encrypted code repre- 
sentative of the apparatus printing the indicia and other 
information uniquely determinative of the legitimacy of 
postage on the mailpieces. 

io A digital meter provides evidence of the payment of 
postage by signing the postal information on the enve- 
lope with two "digital tokens." One digital token provides 
evidence to the postal service, and the second digital 
token provides evidence to the vendor, such as the 

15 assignee of the present invention. A digital token is a 
truncation of the result of encrypting indicia information 
including, for example, postage value, piece count date 
of submission, and originating post office. 

A new class of digital meters is being developed 

20. that employ cryptographic means to produce evidence 
of postage payment. The encryption is performed using 
a cryptographic key. In each digital meter, independent 
keys are used for generating the digital tokens. For 
security reasons, the keys in different meters are also 

25 independent. Information about the meter and mail 
piece are combined and encrypted with vendor and 
postal master keys or keys derived therefrom. Portions 
of the resulting information are printed on the mail piece 
as digital tokens. The information and tokens can be 

30 verified by a device that processes the information in the 
same manner and compares the resulting digital tokens 
with those printed on the mail piece. 

A key management system is needed to distribute 
cryptographic keys to digital meters in a secure and reli- 

35 able manner. The key management system must 
include means for verifying indicia and digital tokens to 
detect the fraudulently generated of indicia and dupli- 
cated indicia. 

It is desired that the key management system have 

40 the capability to manufacture meters without assigning 
meters to a destination country, i.e. manufacturing 
generic meters that could be inventoried. However, 
manufacturing generic meters creates a problem that 
suggests either the need to install keys in the field, or 

45 the need to translate keys between domains. Either 
alternative presents a significant security and key integ- 
rity threat. It is desired that a key management system 
include means that avoids such problems. 

so Summary of the Invention 

In accordance with the present invention a method 
of token verification in a Key Management System pro- 
vides a logical device identifier and a master key cre- 
55 ated in a logical security domain to a transaction 
evidencing device, such as a digital postage meter. The 
method creates a master key record in a key verification 
box, securely stores the master key record in a Key 
Management System archive, and produces in the 
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transaction evidencing device evidence in the logical 
security domain of transaction information integrity. The 
method inputs the evidence of the transaction informa- 
tion integrity to a token verification box. and inputs in the 
token verification box the master key record from the 
Key Management System archive. The method deter- 
mines in the token verification box that the master key is 
valid in logical security domain, uses in the token verifi- 
cation box the master key to verify the evidence of trans- 
action information integrity, and outputs from the token 
verification box an indication of the result of the verifica- 
tion of the evidence of transaction information integrity. 

The master key record includes the logical device 
identifier, the master key and a digital signature associ- 
ating the logical device identifier and the master key. 
The method checks the digital signature to verify the 
association of the logical device identifier and the mas- 
ter key within the logical security domain. 

In accordance with the present invention, a method 
of token verification in a Key Management System com- 
prises the steps of providing to a transaction evidencing 
device a master key created in a logical security domain 
and a logical device identifier; creating a master key 
record in a key verification box; securely storing the 
master key record in a Key Management System 
archive; creating a temporal token key record using the 
master key in a token key distribution box; securely stor- 
ing the token key record in a Key Management System 
archive; producing in the transaction evidencing device 
the token key; producing in the transaction evidencing 
device evidence in the logical security domain of trans- 
action information integrity using the token key; input- 
ting the evidence of the transaction information integrity 
to a distributed token verification box; inputting in the 
distributed token verification box the token key record 
from the Key Management System archive; determining 
in the distributed token verification box that the token 
key is valid in logical security domain; using in the dis- 
tributed token verification box the token key to verify the 
evidence of transaction information integrity; and out- 
putting from the distributed token verification box an 
indication of the result of the verification of the evidence 
of transaction information integrity. 

The token key record includes the logical device 
identifier, the token key and a digital signature associat- 
ing the logical device identifier and the token key. The 
step of determining in the distributed token verification 
box that the token key is valid in logical security domain 
comprises the step of and checking the digital signature 
to verify the association of the logical device identifier 
and the token key within the logical security domain. 

The Key Management System includes means for 
generating, distributing and managing cryptographic 
keys used by an information transaction system that 
employs cryptographic means to produce evidence of 
information integrity. The system comprises a plurality 
of functionally distinct secure boxes operatively coupled 
to each other. Each of the secure boxes performs func- 
tions for key generation, key installation, key verification 



or validation of tokens. Computers, operatively coupled 
to the secure boxes, provide system control and facili- 
tate communication among the secure boxes. A plurality 
of separate logical security domains provide domain 

5 processes for key generation, key installation, key verifi- 
cation and validation of tokens produced by the transac- 
tion evidencing device within the domain using the key 
management functions. A plurality of domain archives, 
corresponding respectively to each of the security 

w domains, securely and reliably record key status 
records and master keys for each domain. The Key 
Management System installs the master keys in the 
transaction evidencing device and validates the tokens. 
The secure boxes include a key generation box for gen- 

is erating, encrypting and signing a master key; a key 
installation box for receiving, verifying and decrypting 
the signed master key and for installing the master key 
into the transaction evidencing device; a key verification 
box for verifying the installation of the master key in the 

20 transaction evidencing device, a token verification box 
for verifying the tokens, and at least one manufacturing 
box for generating domain keys and distributing the 
domain keys among the secure boxes for each of the 
domains. 

25 In accordance with the preferred embodiment of the 
present invention, a Key Management System gener- 
ates and distributes cryptographic keys, such as Vendor 
keys, USPS keys, and other country's postal keys, to 
digital meters for multiple domains. A domain is a logical 

30 separation of data and functions enforced by unique 
domain authentication and confidentiality keys. The Key 
Management System prevents any translation of keys 
between domains, provides assurance in a domain that 
the keys were generated in the domain, and that they 

35 have been installed in only one meter by the system. 
The Key Management System securely distributes and 
maintains cryptographic keys for multiple domains. Fur- 
ther, the Key Management System is structured so that 
key management for all domains is identical. 

40 The Key Management System supports the follow- 
ing security requirements: (i) meter keys are always 
confidential; (ii) ability to verify indicia information con- 
tinues for the life of the system; (iii) status of meter mas- 
ter keys must always be accurately maintained; (iv) 

45 separation of domains must be maintained in order to 
generate and verify indicia; and (v) a key is installed, or 
attempted to be installed only once. 

Description of the Drawings 

50 

The above and other objects and advantages of the 
present invention will be apparent upon consideration of 
the following detailed description, taken in conjunction 
with accompanying drawings, in which like reference 
55 characters refer to like parts throughout, and in which : 

Fig. 1 is a block diagram of a cryptographic key 
management and validation system in accordance 
with the present invention; 
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Fig. 2 is a block diagram showing the relationship of 

the security domains in the key management and 

validation system of Fig. 1 ; 

Fig. 3 is a block diagram of a vendor data center in 

the key management and validation system of Fig. 

1; 

Fig. 4 is a block diagram of the vendor manufactur- 
ing facility in the key management and validation 
system of Fig. 1 ; 

Fig. 5 is a block diagram of a postal data center in 
the key management and validation system of Fig. 
1; 

Fig. 6 is a block diagram showing the administrative 
domain of a manufacturing box in the key manage- 
ment and validation system of Fig. 1 ; 
Fig. 7 is a flow diagram of a key management proc- 
ess; 

Fig. 8 is a flow chart for key identification; 

Fig. 9 is a block diagram of the key material for the 

manufacturing box; 

Fig. 10 is a block diagram of the key material for the 
oak box; 

Fig. 1 1 is a block diagram of the key material for the 
steel box; 

Fig. 12 is a block diagram of the key material for the 
brass box; 

Fig. 13 is a flow diagram of an Earth domain digital 
meter process; 

Fig. 14 is a flow diagram of valid master key status 
transitions; 

Fig. 1 5 is a block diagram of valid master key status 
transitions; 

Fig. 16 is a message from oak box to brass box; 
Fig. 17 is a message from oak box to steel box; 
Fig. 18 is logic diagram for key freshness detection; 
Fig. 19 is a message from steel box to brass box; 
Fig. 20 is a message from a meter to brass box; 
Fig. 21 is a block diagram of error handling; 
Fig. 22 is a flow diagram of an initialization of a first 
manufacturing box; 

Fig. 23 is a flow diagram of an initialization of a 
generic box; 

Fig. 24 is a flow diagram of the processing of a key 
request; 

Fig. 25 is a flow diagram of the processing of a key 
installation; 

Fig. 26 is a flow diagram of the processing of a key 
registration; 

Fig. 27 is a flow diagram of the processing of an 
obsolete key: 

Fig. 28 is a flow diagram of verification processing. 
Fig. 29 is a block diagram showing the flow of key 
installation messages; 

Fig. 30 is a table of the key installation messages of 
Fig. 29; 

Fig. 31 is a table of key registration messages; and 
Fig. 32 is a block diagram showing the relationship 
of domains and sub-domains. 



Detailed Description of the Present Invention 

In describing the present invention, reference is 
made to the drawings, wherein there is seen various 
5 aspects of a Key Management and Validation System, 
also referred to herein as the Key Management System. 

SYSTEM OVERVIEW 

io Referring now to Fig. 1, a block diagram of a Key 
Management System provides an overview of the loca- 
tion and information flow of the Key Management Sys- 
tem components. The Key Management System, 
generally designated 10, encompasses vendor facilities 

is 12 and 14 and postal facilities 16 and 18. The vendor is 
the entity that manages the Key Management System. 
Key Management System 10 includes a plurality of 
functionally dedicated secure boxes, computers and 
communications lines. In accordance with the present 

20 invention, Key Management System 10 provides manu- 
facturing and operational support for a new generation 
of digital meter products. Reference herein to digital 
meters and digital meter products will be of such new 
generation of digital meter products. It is noted that the 

25 present invention is suitable for managing the genera- 
tion, distribution of cryptographic keys and the verifica- 
tion of cryptographic data for other applications as well. 

In accordance with the present invention, vendor 
and postal master keys are generated, archived and 

30 installed in meters by components of Key Management 
System 10. Postal token keys are derived, distributed 
and used for remote verification by components of Key 
Management System 10. Vendor and postal tokens are 
verified by components of Key Management System 10. 

35 Key Management System 10 supports the installa- 
tion and long term maintenance of encryption keys in 
digital meter products. The generation of master keys is 
supported by Master Key Generation Boxes 20 and 22, 
which are also referred to herein as Oak Boxes, an 

40 attached Key Management System computer 24, also 
referred to herein as the KMC, and archive server 25. 
The distribution of master keys is supported by a Key 
Distribution Computer 30, also referred to herein as the 
KDC. The installation of master keys is supported by a 

45 Master Key Installation Box 32, which is also referred to 
herein as Steel Box. and an attached Parameterization, 
Seeding And Registration (PSR) Computer 34. Central- 
ized verification of printed digital tokens is supported by 
Token Verification Boxes 21 and 40. which are also 

so referred to herein as Brass Boxes, and attached respec- 
tive Key Management System computers 24 and 42. 
Key Archives 25 and 45 securely and reliably record key 
status messages and keys. 

55 Security Domains 

Referring now to Fig. 2, Key Management System 
10 includes separate logical security domains: one ven- 
dor domain 50 and one or more domains 52 for postal 



4 



7 EP 0 735 720 A2 8 



authorities. Each domain provides a full set of key gen- 
eration, key distribution, key installation and token veri- 
fication services. Each domain may encompass several 
facilities, such as vendor and postal facilities. Multiple 
logical security domains may exist within each secure 5 
box. Separation of such multiple domains is achieved by 
encryption of the domain messages in the Master Key 
Database. The Database encryption keys are different 
for each domain. Within a secure box, the separation of 
domains is by the limited processes enabled in the box. 
However, the security domains overlap in only one 
place, inside a digital meter. The digital meter calculates 
two proof of payment tokens, one using the vendor mas- 
ter key and the other using the postal master key. Fail- 
ure in the verification of either digital token is sufficient 
proof of fraud. 

Referring now to Fig. 3, vendor data center 12 pro- 
vides physical and information access control for Key 
Management System components. Vendor data center 
12 houses at least one Oak Box 20 that functions as a 
Vendor Master Key Generation Box, at least one Brass 
Box 21 that functions as a Vendor Token Verification 
Box and a Manufacturing Box 23. For security, each box 
has a unique ID. For added security, the generation, ver- 
ification and manufacturing functions are physically sep- 
arated from each other, i.e., Oak Box, Brass Box and 
Steel Box are separate boxes. It is noted that more than 
one functional box can be housed in a physical box if so 
desired. 

Vendor KMS Computer 24 manages the secure 
Oak, Brass and Manufacturing boxes and the mes- 
sages between them. It supports secure box communi- 
cations, vendor key archive services, postal key archive 
services and communications with the vendor manufac- 
turing facility 14 and Postal Data Center 16. 

Referring now to Fig. 4, Vendor manufacturing facil- 
ity 14 provides physical and information access control 
for Key Management System components. A vendor 
manufacturing facility 14 houses a vendor Key Distribu- 
tion computer 30 and at least one secure Steel Box 32, 
which functions as a Master Key Installation Box, and a 
corresponding PSR computer 34. Vendor Key Distribu- 
tion and PSR Computers 30 and 34 support communi- 
cations with Key Management System computer 24. 
other secure boxes and on-line digital meters 36. PSR 
Computers 30 manage corresponding Steel Boxes 32 
and the initialization of digital meters 36. 

Referring now to Fig. 5. Postal Data Center 16 may 
provide physical and information access control for Key 
Management System 10 components. Postal Data 
Center 16 may house a Postal Oak Box 22 which func- 
tions as a postal master key generation box and a 
Postal Brass Box 40 which functions as a postal token 
verification box. A Postal Key Management System 
Computer 42 may support secure box communications, 
postal key archive services and communications with 
Mail Facilities 18 and Vendor Data Center 12. 

Referring now to Fig. 6, an additional logical secu- 
rity domain is required to support the installation and 



maintenance of all other security domains in Key Man- 
agement System Components. This is called the Key 
Management System Administration Domain 60 which 
is responsible for the generation of security domains 
and the installation of security domains in Key Manage- 
ment System Components. 

Installation of country specific sub-domains in an 
Earth Security Domain are the responsibility of the 
Earth Security Domain. Installation of Product Code 
parameters within Security Domains are the responsi- 
bility of the affected Security Domains. This will be 
explained in more detail below. 

FUNCTIONAL CHARACTERISTICS 

The following paragraphs provide an overview of all 
operations and messages in Key Management System 
10. 

Key Management System 10 provides several nec- 
essary functions to support the manufacture and opera- 
tion of digital meter products. It is responsible for the 
generation, distribution and long term storage for all 
encryption keys used in digital meter products. It is also 
responsible for the verification of digital tokens gener- 
ated by digital meter products that employ such encryp- 
tion keys. 

Two or more security domains are implemented by 
Key Management System 10. Vendor Security Domain 
50 includes key generation, distribution, archival and 
verification services. Postal security domains 52 imple- 
ment similar services. These domains overlap in one 
point, the digital meter that contains both vendor and 
postal master keys, as shown in Fig. 2, i.e., only in the 
meter are Vendor and Postal Master Keys available 
simultaneously. 

KEY CHARACTERISTICS 

Kev Generation 

Referring now to Fig. 7, a flow diagram of the Key 
Management Process is shown. A digital meter 36 
receives the vendor master key and postal master key 
while physically located in the vendor manufacturing 
facility 14 before distribution. 

The Key Management System secure box manu- 
facturing process and the domain master key genera- 
tion process provides encryption keys for Key 
Management System 10 and digital meters 36. Domain 
master keys for digital meters 36 are generated by a 
Domain Oak Process 70. Domain keys that are used to 
encrypt domain master keys as they are generated, 
archived and installed, are generated by Manufacturing 
Box 23. To provide secure and nondeterminisitic keys, 
two random number generator processes are 
employed. Each Oak Box and Manufacturing Box 
includes a hardware random number generator. A soft- 
ware pseudo-random number generator is also 
included. The output of these two processes are individ- 
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ually tested to verify that the hardware and software are 
operating within acceptable limits. The outputs of the 
two generators are combined through an exclusive-or 
operation. Thus, if the hardware random number gener- 
ator fails, the pseudo-random number generator pro- 
vides acceptable keying material until the hardware 
generator can be fixed. 

Other KMS secure boxes have limited requirements 
to generate keying material. Specifically, startup confi- 
dentiality keys are generated by Brass and Steel Boxes 
21 and 32 during the initialization process. Because of 
the limited requirements and the presence of trusted 
authorities during the initialization process, only soft- 
ware pseudo-random number generators are 
employed. 

Master Key Identification 

Key Management System 10 must enforce the 
security requirement that a master key can only be 
attempted or installed in any digital meter 36 once. For 
example, Key Management System 10 must ensure that 
a domain master key is not installed twice when two or 
more Steel Boxes 32 are used in the system. This 
requirement is satisfied through the use of domain mas- 
ter key identification numbers, which are composed of 
domain specific monotonic sequence counters. Domain 
Oak Processes and Domain Steel Processes track the 
last domain master key identification number received 
for a specific domain ID. When a new Generate Key or 
Install Key message is received, the domain oak proc- 
esses or domain steel processes verify that the domain 
master key identification number is greater than that 
contained in the previous message. 

When Key Management System 10 receives a 
Request Key command, a Steel ID is required. The 
Steel ID'S are included in the Distribute Master Key 
record and must be checked by the Domain Steel Proc- 
ess 76. If the Steel ID in the message does not match 
the Steel ID for the Steel Box, the message is rejected. 
The Steel ID may not be modified in the message with- 
out breaking the message signature. The combination 
of Domain Master Key Identification Number, Steel ID 
and message signature satisfies a one time installation 
requirement. 

Referring now to Fig. 8, Key Distribution Computer 
30 requests a key at 80. At 82, Key Management Sys- 
tem computer 24 generates a new monotonically 
increasing key ID from a domain archive 74. At 84, 
domain oak process 70 determines whether the Oak 
Box key ID is new against a last seen value. If it is not 
new, then an Oak Box error condition is initiated at 86. If 
the key ID is new, then at 88 Oak Box 20 generates and 
encrypts a key, attaches the key ID, and then signs and 
sends the message to Steel Box 32. At 90 domain steel 
process 76 determines whether the Steel ID is correct. 
At 92 domain steel process 76 determines if the key ID 
is new against a last seen value. A steel box error 
occurs if the message signature test fails, the steel ID is 



not correct or the key ID is not new. If no error occurs 
Steel Box 32 installs the key into a meter 36 at 98. 

Manufacturing Bqx and Dpmajn keys 

5 

Referring now to Figs. 9-12, secure Boxes within 
Key Management System 10 must be initialized with 
domain configuration information and keying material. 
This is achieved through the use of Manufacturing Box 

10 23 which is responsible for the creation of domains and 
the domain keys 110. When a domain is created, a 
unique domain ID is required. After a domain has been 
established in Manufacturing Box 23. other secure 
boxes may be initialized with the domain information. 

is All domain keys 1 10 are generated by Manufactur- 
ing Box 23. Domain keys 110 consist of confidentiality, 
authentication and operation keys that are encrypted by 
Domain Key Set 103. Domain keys 110 are shared 
among the different secure boxes. Each secure box has 

20 specific requirements for keying material. 

Each Manufacturing Box 23 requires an Operation 
Combination 101 that is broken into three Shamir secret 
shares 102. Individual shares are written onto remova- 
ble media and distributed to authorized personnel. Each 

25 Manufacturing Box 23 requires a Domain Key Set 103 
that consists of an RSA key pair for confidentiality and 
an RSA key pair for authentication. The confidentiality 
and authentication keys are broken into three Shamir 
secret shares 104. Individual shares are written onto 

30 removable media and distributed to authorized person- 
nel. RSA key pairs are described in "A Method For 
Obtaining Digital Signatures And Public-Key Cryptosys- 
tems," by R. L Rivest, A. Shamir and L Adleman in 
Communications of the ACM, Vol. 21, No. 2, February 

35 1978, pp. 120-127. Shamir secret shares are described 
in "How To Share A Secret," by A. Shamir in Communi- 
cations of the ACM, Vol. 22 . No. 1 1 , Nov. 1 979, pp. 61 2- 
613. 

In the preferred embodiment, each Oak Box 20 

40 requires an Operation Combination 105 that is broken 
into two Shamir secret shares 106 (Fig. 10). Individual 
shares 106 are written onto removable media and dis- 
tributed to authorized personnel. All shares 106 must be 
entered into Oak Box 20 before it can operate. The last 

45 entered share 106 must remain in the Oak Box to keep 
it enabled. When the last entered share 106 is removed, 
Oak Box 20 is disabled. 

Each Domain Oak Process 70 requires an RSA key 
pair for authentication. The private authentication key 

so (P'OA) is only known by the Domain Oak Process 70 
and Manufacturing Box 23. The public authentication 
key (POA) is known by the corresponding Domain Steel 
Process 76 and Domain Brass process 72. The Domain 
Oak Process 70 does not require a private confidential- 

55 ity key. 

In the preferred embodiment, each Steel Box 32 in 
the vendor Manufacturing Facility requires an Operation 
Combination 119 that is broken into two Shamir secret 
shares 120 (Fig. 11). Individual shares 120 are written 
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onto removable media and distributed to authorized per- 
sonnel, for example to a supervisor and operator. The 
set of Supervisor and Operator shares 120 must be 
entered into Steel Box 32 before it can operate. The last 
entered share 106, for example the operator share, 
must remain in Steel Box 32 to keep it enabled. When 
operator share 120 is removed, Steel Box 32 is disa- 
bled. 

Each Domain Steel Process 76 requires an RSA 
key pair for authentication. The private authentication 
key is only known by the Domain Steel Process 76. The 
public authentication key is only known by the Domain 
Brass Process 72. Each Domain Steel Process 76 
requires an RSA key pair for confidentiality. The private 
confidentiality (P'sc) key is only known by the Domain 
Steel Process 76. The public confidentiality (Psc) key is 
known by the Domain Oak Process 70. 

In the preferred embodiment of the present inven- 
tion, each Brass Box 21 requires an Operation Combi- 
nation 121 that is broken into two Shamir secret shares 
122 (Fig. 12). Individual shares 122 are written onto 
removable media and distributed to authorized person- 
nel. All shares 122 must be entered into a Brass Box 21 
before it can operate. The last entered share 122 must 
remain in Brass Box 21 to keep it enabled. When the 
last entered share 122 is removed, Brass Box 21 is dis- 
abled. 

Each Domain Brass Process 72 requires an RSA 
key pair for authentication. The private and public 
authentication keys (P'BA and PBA) are only known by 
the Domain Brass Process. Each Domain Brass Proc- 
ess requires an RSA key pair for confidentiality. The pri- 
vate confidentiality key (P' BC ) is only known by Domain 
Brass Process 72. The public confidentiality (PBC) key 
is known by the Domain Oak Process 70. Each Domain 
Brass Process 72 requires a DES key set for confidenti- 
ality that is only known by the Domain Brass Process 
72. Each Domain Brass Process 72 requires a DES key 
set for authentication that is only known by the Domain 
Brass Process 72. 

It will be understood by those skilled in the art that 
the number of shares selected as being necessary to 
operate the secure boxes is based on the security strat- 
egy implemented for the Key Management System. 

Digital Meter Requirements 

A manufacturing sequence number, in conjunction 
with a product code number, uniquely defines digital 
meter 36 within the vendor manufacturing process. The 
preferred method for the manufacturing sequence 
number allocation is as follows. A supply of identification 
labels, each containing a unique product code number 
and manufacturing sequence number pair, is stocked on 
the manufacturing line. One identification label is 
applied to each digital meter 36. These numbers are 
entered into the PSR Computer 34 and downloaded into 
digital meter 36 prior to the Key Installation process. 



The meter is securely configured so that once keys 
are installed during manufacture, they can never be 
removed or determined outside the manufacturing envi- 
ronment without leaving physical evidence of tamper- 
5 ing. 

The Domain Oak Process 70 employs a set of test 
information during the Master Key Generation process. 
A Test Pattern is used to generate a set of test tokens to 
check the Master Key Installation process in Manufac- 
w turing. The Test Pattern consists of two Preformatted 64 
bit binary values. These are encrypted with the target 
Domain Master Key and the specified position and 
number of tokens from the resulting cyphertext is gener- 
ated. 

is The Test Pattern is included in the Domain Oak and 
Domain Brass Processes operating software. All digital 
meters employ the same test information during the key 
installation check procedure. The test pattern is a set of 
information shared between Key Management System 

20 1 0 and the target digital meter. The test pattern may be 
stored in ROM for a specific digital meter. 

Earth Domain Digital Meters 

25 Earth Domain digital meters do not have country 
specific information when they leave the Manufacturing 
Facility. This is done to allow digital meters to be 
stocked on a regional basis and be made country spe- 
cific at the last moment. The product code number for 

30 an Earth Domain digital meter is a two letter product 
code prefix followed by a predetermined number. Prior 
to country personalization, an Indicia Serial Number will 
be a null string. Both Product Code Number and Indicia 
Serial Number values must be defined at Key Registra- 

35 tion time to make the Domain Master Key active. 

Referring now to Fig. 1 3, a process flow diagram for 
an earth domain digital meter is provided. Earth Domain 
master keys for Earth Domain digital meters are gener- 
ated by the Earth Domain Oak Process 170. Copies of 

40 Earth Domain master keys are stored in the Earth 
Domain Archive 174. Earth Domain master keys are 
installed into Earth Domain digital meters 136 and 
checked by the Earth Domain Steel Process 176. Instal- 
lation of Earth Domain master keys is verified by the 

45 Earth Domain Brass Process 172. The Earth Domain 
Master Key record is updated to install status by the 
Earth Domain Brass Process 172. The Earth Domain 
Brass Process 172 does not participate in Key Registra- 
tion. 

so Authorized personnel assigns the Earth Domain 
digital meter 136 to a country specific security domain 
by setting the digital meter product code number and 
indicia serial number. Once the digital meter 236 has 
been assigned to a country specific security domain, it 

55 cannot return to the Earth Domain. A digitally signed 
Key Registration record is generated by the digital 
meter containing the Product Code Number, Indicia 
Serial Number and Manufacturing Sequence Number. 
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The digitally signed Key Registration record is returned 
to Key Management System Computer 24. 

Key Management System Computer 24 will retrieve 
the Earth Domain Master Key record from the Earth 
Domain Archive 176. The Earth Domain Master Key 5 
record and the Key Registration record is sent to the 
country specific Domain Brass Process 272. The 
records are verified, tf no problems are found, the 
Domain Master Key is encrypted with the country spe- 
cific secret key. The Domain Master Key record is 
signed for integrity and authentication by the country 
specific Security Domain private key. The Domain Mas- 
ter Key record will be sent to the country specific 
Domain Archive 274. 

SYSTEM REQUIREMENTS 

Domain Archive 

Domain Archives 74 support the long term storage 
and retrieval of Domain master keys. This is accom- 
plished with several transactions between the Oak Box 
20, Domain Archive 74 and Brass Box 21 . As the digital 
meter passes through manufacturing, distribution and 
customer sites, the Domain Master Key Status is 
updated. Every status change is logged to the Domain 
Archive records, providing a complete history of key 
activity for the life of the Domain Master Key. 

Referring now to Figs. 14 and 15, a process flow 
diagram that shows valid master key status transitions is 
provided. After Oak Box 20 completes the key genera- 
tion process, an encrypted copy of the Domain Master 
Key and information is forwarded to the Domain Archive 
74. The status of the Domain Master Key will be set to 
New at 180. The Domain Archive 74 will allocate data- 
base storage and write the information. 

After Steel Box 32 and Brass Box 21 complete the 
key installation process, the Domain Master Key record 
is updated. The status of the Domain Master Key may 
be set to Installed at 182 , if the process was successful. 
The status of the Domain Master Key may be set to Bad 
at 184, if any failures occur during the key distribution or 
installation process. Such failures could include a lost 
message, message error, error writing the Domain Mas- 
ter Key to the digital meter memory, error in checking 
the test tokens or others. 

When the digital meter is assigned an Indicia Serial 
Number for a specific postal domain, the Vendor and 
Postal Domain Master Key Records are updated. The 
Master Key status is set to Active at 186 and verification 
services are allowed for that digital meter. When the dig- 
ital meter is taken out of service, the Vendor and Postal 
Domain Master Key record are updated. The Master 
Key status is set to Obsolete at 188. 

Key Management System Addresses 

Key Management System 10 is composed of a set 
of physical secure boxes and logical security domains. 



Messages f towing between these components must 
contain sufficient information to allow processes and 
auditors to identify the message participants. 

Logical security domains are determined by an 
address object called Domain ID. This address uniquely 
defines an instance of a particular domain within Key 
Management System 10. Examples of valid Domain IDs 
may be VE for a vendor Security Domain, USPS for the 
instance of a United Stated Postal Service Security 
Domain and UKRM for the instance of a United King- 
dom Royal Mail Security Domain. Security domains 
span several secure boxes and may span several 
archives. Multiple security domains may coexist within 
the physical boundaries of one secure box. Only one 
domain is active within a secure box at any given time. 
No data is transferable between domains. 

Logical secure box objects are determined by an 
address object called Secure Box Type. This address 
uniquely defines the secure box function participating in 
a message transaction. The Oak Box 20 is the Master 
Key Generator. The Steel Box 32 is the Master Key 
Installation Box. The Brass Box 21 is the Token Verifica- 
tion Box. The Tin Box 44 is the Remote Token Verifica- 
tion Box. 

Identification of physical secure boxes is deter- 
mined by an address object called Secure Box ID. This 
address uniquely defines an instance of that box within 
Key Management System 10. It is composed of a 
Secure Box Type and numeric identifier. 

KMS Configuration Data 

Each component of Key Management System 10 
maintains several configuration tables that allow the 
operating software to determine the validity and 
processing requirements for Key Management System 
service messages. Command tables are used to iden- 
tify what Key Management System service messages 
and commands are expected by components of the sys- 
tem. A KMS system command table defines ail com- 
mands that are accepted on a system level. Subsets of 
the system level table are stored by components of the 
system, including the Oak Boxes 20, Brass Boxes 21, 
Steel Boxes 32. Manufacturing Boxes 23, KMS Compu- 
ter 24, Key Distribution Computer 30 and PSR Comput- 
ers 34. Received messages that are not included in the 
local command table are rejected. 

Configuration tables are used to identify what Key 
Management System Domain IDs are recognized by 
components of the system. A KMS system configuration 
table defines all Domain IDs that are accepted on a sys- 
tem level. Subsets of the system level table are stored 
by components of the system, including the Oak Boxes 
20, Brass Boxes 21, Steel Boxes 32, Manufacturing 
Boxes 23, KMS Computer 24, Key Distribution Compu- 
ter 30 and PSR Computers 34. Received messages for 
Domain IDs that are not included in the local configura- 
tion table are rejected. 
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Record tables are used to identify what Key Man- 
agement System Records are recognized by compo- 
nents of the system. A KMS system record table defines 
all information records that are recognized on a system 
level. Subsets of the system level table are stored by 
components of the system, including the Oak Boxes 20. 
Brass Boxes 21, Steel Boxes 32, Manufacturing Boxes 
23. KMS Computer 24, Key Distribution Computer 30 
and PSR Computers 34. Received messages contain- 
ing information records that are not included in the local 
record table are rejected. 

Information Flow 

The Domain Oak Process 70 delivers the Domain 
Master Key to the Domain Archive 74. Referring now to 
Fig. 16, the Domain Master Key (Kqm) encrypted with 
the Domain Brass Process public key (P B c) before it is 
stored in the Domain Archive 74. Thus, the Domain Oak 
Process 70 may not decrypt the Domain Master Key 
(Kqm) from the Domain Archive 74. The Domain Oak 
Process 70 signs the Domain Master Key record with 
the Domain Oak Process private key (P 0 a) before it is 
stored in the Domain Archive 74. Thus, the Domain 
Brass Process 72 can trust that the Domain Master Key 
record was created by the Domain Oak Process 70. 

The Domain Oak Process 70 delivers the Domain 
Master Key (K DM ) to the Domain Steel Process 76. 
Referring now to Fig. 17, the Domain Master Key (K DM ) 
is encrypted with the Domain Steel Process public key 
P(sc) before it is sent to the Domain Steel Process 76. 
Thus, the Domain Oak Process 70 may not decrypt the 
Domain Master Key (Kqm) from a Distribute Master Key 
record. The Domain Oak Process 70 signs the Distrib- 
ute Master Key record with the Domain Oak Process 
private key P'(oa) before it is sent to the Domain Steel 
Process 76. Thus, the Domain Steel Process 76 can 
trust that the Distribute Master Key record was created 
by the Domain Oak Process 70. 

Referring now to Fig. 18, the process flow for key 
freshness detection is shown. To support the previously 
noted security requirements, a key is installed or 
attempted to be installed only once to assure Domain 
Master Key freshness. The Domain Archive assigns 
monotonically sequenced Key IDs (KID) to all Domain 
master keys. Separate Key ID indexes are maintained 
for each Domain ID. The Domain Oak Processes 70 
and Domain Steel Processes 76 track the Key ID values 
and compare them to Key ID values received in the 
Generate Key message and Distribute Master Key 
record. Thus, the Domain Oak Processes 70 and 
Domain Steel Processes 76 can detect when a Gener- 
ate Key message or Distribute Master Key record is 
replayed. 

Referring now to Fig. 19, the Domain Steel Process 
76 signs the Master Key Install record with Domain 
Steel Process private key P( SA ) before it is sent to the 
KMS Computer 24. By doing so, the Domain Brass 



Process 72 can trust that the Master Key Install record 
was created by the Domain Steel Process 76. 

At time of Key Registration, the digital meter signs 
the Key Registration record with both the vendor Master 
5 Key K(vm) and the postal Master Key K( PM ). Thus, the 
Postal and Vendor Domain Brass Processes 72 can 
trust that the Key Registration record values originated 
at digital meter 36. Each Domain Brass Process 72 then 
encrypts the Domain Master Key in the Domain Archive 
10 record with a Domain Brass Process secret DES key. 
As a result, Domain Brass Processes 72 can trust that 
other Domain Brass Processes may not read the keying 
material. The Domain Brass Process 72 signs the 
Domain Master Key record with the Domain Brass Proo- 
fs ess secret DES key before sending it to the Domain 
Archive 74. Thus, the Domain Brass Process 72 can 
trust that the Domain Master Key record was only mod- 
ified by the Domain Brass Process 72. An example of a 
meter to Brass Process message is shown in Fig. 20. 

20 

Audit Trail 

Key Management System 10 maintains an audit 
trail of time events in the life of a Domain Master Key. 

25 These events indicate when actions are taken by Key 
Management System 10. The time events listed must 
be increasing for successful Domain Master Key use. 
System messages with time events preceding previous 
events will be rejected. Verification requests received 

30 with dates preceding the Key Management System Key 
Registration time will be rejected. 

In the preferred embodiment of the present inven- 
tion, the KMS Computer 24 records the KMS Request 
Time which is when a Request Key command is 

35 received from the Key Distribution Computer 30. The 
PSR Computer 34 records the PSR Install Time which 
is when an Install Key command is delivered to a Steel 
Box 32. The KMS Computer 24 records the KMS Install 
Time which is when an Install Key Verification command 

40 is received from the Key Distribution Computer 30. The 
digital meter 36 records the Meter Registration Date 
which is when a Register Indicia command is received 
from the communications port or user interface. The 
KMS Computer 24 records the KMS Key Registration 

45 Time which is when a Register Indicia Verification com- 
mand is received from the digital meter. 

In an alternate embodiment, the Oak Box 20 
records a local time when the Generate Key command 
is received from the KMS computer 24. The Steel Box 

so 32 records a local time when the Install Key command is 
received. The Brass Box 21 records a local time when a 
Key Verification request is received from Key Manage- 
ment System computer 24. 

55 Error Handling 

Key Management System 10 provides a set of error 
detection and reporting mechanisms for Key Manage- 
ment System service messages. Problems may occur 
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when messages are prepared, sent over communica- 
tions lines, received or processed by the receiving party. 
When errors are detected in the system, the command 
source will be notified and an entry will be made in the 
system Error Log. 

Referring now to Fig. 21, a block diagram showing 
an overview ol error handling is provided. Errors in the 
system are detected in three different levels. The first 
level of error handling is implemented within the PB232 
protocol. This protocol provides for message framing 
through the use of STX and ETX control characters. 
Message identification is provided through the use of 
predefined Class Codes. Message integrity is provided 
through the use of error detection codes. If the received 
message complies with these mechanisms, the receiver 
will send a positive Acknowledgment control character. 
If not, the receiver will send a Non-Acknowledgment 
control character. The sending component may attempt 
to retry transmission of the message or take other cor- 
rective action. PB232 error handling mechanisms are of 
a conventional type. 

The second level of error handling is implemented 
by Key Management System 10 command handler 
processes. These compare the received command with 
a set of expected commands as defined in a Command 
Table. The command field is verified. The number of 
expected parameters is checked. The syntax of individ- 
ual parameters is checked. If any errors are found in the 
command, a Command Error message will be returned 
to the command source. 

The third level of error handling is implemented by 
Key Management System 10 command handler proc- 
esses. These compare the parameters in the command 
against a set of expected parameters as defined in a 
Configuration Table. Individual parameters are checked 
against the Configuration Table. The association of dif- 
ferent parameters is checked against the Configuration 
Table. The availability of hardware resources and data- 
base records is checked. Signatures of message com- 
ponents and the validity of encrypted message 
components are checked. If any errors are found in the 
command or during command processing, a Command 
Response message will be returned with a Response 
Code. If any errors are found in the Response, a Com- 
mand Response Error message will be returned with a 
Response Code. 

Initialization Process 

The following paragraphs provide an overview of 
Key Management System 10 Secure Box Initialization 
Process, as shown in Figs. 22 and 23. As previously 
described, in the preferred embodiment of the present 
invention there are four Key Management System 
Secure Box types. Manufacturing Box 23 is responsible 
for Key Management System and Secure Box initializa- 
tion. Oak Box 20 is responsible for Domain Master Key 
Generation. Steel Box 32 is responsible for Domain 
Master Key installation. Brass Box 21 is responsible for 



Domain Master Key Registration and Token Verification. 
In an alternate embodiment, Tin Box is a Remote Token 
Verification Box. 

Referring now to Fig. 22, the First Manufacturing 

5 Box 23 must be initialized. The Manufacturing Box oper- 
ating software is loaded and tested. The Secure Box ID 
is initialized to M00000000. When Manufacturing Box 
23 is turned on, the Secure Box ID is queried. If it is set 
to M0O000O00. Manufacturing Box 23 waits for a Set 

io First Secure Box ID message from the KMS Computer 
24. KMS Computer 24 then commands the First Manu- 
facturing Box 23 to set the Secure Box ID to 
M00000001. First Manufacturing Box 23 then receives 
and checks the message. If no errors are found. First 

is Manufacturing Box 23 generates an Operation Combi- 
nation 101 and set of Operation Share keys 102. The 
Operation Share keys 102 are written to removable 
media. 

Next, First Manufacturing Box 23 generates two 
20 RSA key pairs, one for Domain Key Set Confidentiality 
and the other for Domain Key Set Authentication. These 
keys are broken into Domain Shares and written onto 
removable media. The keys are used to encrypt and 
sign Domain Key sets before they are sent to the KMS 
25 Computer 24 and written to the Archive or to removable 
media. First Manufacturing Box 23 generates a set of 
Secure Box Authentication keys. An RSA key pair is 
generated for each box type, i.e., Manufacturing, Oak. 
Steel and Brass. The public key for each box type is 
30 written to removable media. The keys must then be writ- 
ten into Secure Box Operating Software by Software 
Engineering. After all the Operation Shares and authen- 
tication keys have been successfully written, the Secure 
Box ID will be set to M00000001 . 
35 KMS Computer 24 requests Manufacturing Box 23 
to create a Domain. Manufacturing Box 23 establishes 
the Domain ID in internal memory and generates the 
required Domain Keys 1 10 which are encrypted with the 
Domain Key Set 103 Confidentiality key and signed with 
40 the Domain Key Set 103 Authentication Key. The 
encrypted and signed Domain Keys are written to the 
Archive and/or to removable media. 

Additional Manufacturing Boxes 23 are initialized by 
a Source Manufacturing Box, which is any manufactur- 
es ing box that has been initialized. The Manufacturing Box 
operating software is loaded and tested in each addi- 
tional Manufacturing Box 23. The Secure Box ID is set 
to M00000000. When Manufacturing Box 23 is first 
turned on, it queries the Secure Box ID. If it is 
so M00O0OOO0, Manufacturing Box 23 waits for a Set 
Secure Box ID message from the Source Manufacturing 
Box. KMS Computer 24 commands the Source Manu- 
facturing Box to initialize each additional Manufacturing 
Box 23. The Source Manufacturing Box allocates the 
55 next Manufacturing Secure Box ID, signs the message 
with the Manufacturing Box Private Startup Authentica- 
tion Key and sends it to Manufacturing Box 23. Manu- 
facturing Box 23 stores the Secure Box ID and 
generates a Manufacturing Box Startup Confidentiality 
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Key. The Secure Box ID and Public Startup Confidenti- 
ality Key are sent back to the Source Manufacturing Box 
and signed with the Manufacturing Box Private Startup 
Authentication Key. KMS Computer 24 commands the 
Source Manufacturing Box to make a Domain Manufac- 5 
turing Process for the Manufacturing Box. The required 
Domain Key components are delivered to Manufactur- 
ing Box 23 using the Startup Confidentiality Key. This 
process is repeated for all required Domains. 

Any time domains are added to a Manufacturing 10 
Box 23, other initialized Manufacturing Boxes must be 
updated to reflect such additional domains. In the pre- 
ferred embodiment, all initialized Manufacturing Boxes 
are configured with identical key data. 

For Oak Box initialization, the Oak Box operating 15 
software is loaded and tested. The Secure Box ID is set 
to O00000000. When Oak Box 20 is first turned on, it 
queries the Secure Box ID. H it is O00000000. Oak Box 
20 waits for a Set Secure Box ID message from Manu- 
facturing Box 23. KMS Computer 24 commands Manu- 20 
facturing Box 23 to initialize Oak Box 20. Manufacturing 
Box 23 allocates the next Oak Secure Box ID, signs the 
message with the Private Oak Box Startup Authentica- 
tion Key and sends it to Oak Box 20, which stores the 
Secure Box ID and generates an Oak Box Startup Con- 25 
fidentiality Key. The Secure Box ID and Public Startup 
Confidentiality Key are sent back to the Manufacturing 
Box, signed with the Oak Box Public Startup Authentica- 
tion Key. KMS Computer 24 commands Manufacturing 
Box 23 to make a Domain Oak Process for Oak Box 20. 30 
The required Domain Key components are delivered to 
Oak Box 20 using the Startup Confidentiality Key. This 
process enables Oak Box 20 to implement the Domain 
Oak Process 70 for one domain. This process is 
repeated for all domains required for a particular Oak 35 
Box. 

For Steel Box initialization, the Steel Box operating 
software is loaded and tested. The Secure Box ID is set 
to S00000OO0. When Steel Box 32 is first turned on, it 
queries the Secure Box ID. If it is S00000000, Steel Box 40 
32 waits for a Set Secure Box ID message from Manu- 
facturing Box 23. KMS Computer 24 commands Manu- 
facturing Box 23 to initialize Steel Box 32. 
Manufacturing Box 23 allocates the next Steel Secure 
Box ID, signs the message with the Steel Box Private 45 
Startup Authentication Key and sends it to Steel Box 32. 
Steel Box 32 stores the Secure Box ID and generates a 
Steel Box Startup Confidentiality Key. The Secure Box 
ID and Public Startup Confidentiality Key are sent back 
to Manufacturing Box 23, signed with the Steel Box pub- so 
lie Startup Authentication Key. KMS Computer 24 com- 
mands Manufacturing Box 23 to make a Domain Steel 
Process 76 for Steel Box 32. The required Domain Key 
components are delivered to Steel Box 32 using the 
Startup Confidentiality Key. This process enables Steel ss 
Box 32 to implement the Domain Steel Process 76 for 
one domain. This process is repeated for ail domains 
required for a particular Steel Box. 



For Brass Box initialization, the Brass Box operating 
software is loaded and tested. "Rie Secure Box ID is set 
to BOOO00O0O. When Brass Box 21 is first turned on, it 
queries the Secure Box ID. If it is BO0OOO000. Brass Box 
21 waits for a Set Secure Box ID message from Manu- 
facturing Box 23. KMS Computer 24 commands Manu- 
facturing Box 23 to initialize Brass Box 21. 
Manufacturing Box 23 allocates the next Brass Secure 
Box ID, signs the message with the Brass Box Private 
Startup Authentication Key and sends it to Brass Box 
21. Brass Box 21 stores the Secure Box ID and gener- 
ate a Brass Box Startup Confidentiality Key. The Secure 
Box ID and Public Startup Confidentiality Key are sent 
back to Manufacturing Box 23, signed with the Brass 
Box Public Startup Authentication Key. KMS Computer 
24 commands Manufacturing Box 23 to make a Domain 
Brass Process for Brass Box 21. The required Domain 
Key components are delivered to Brass Box 21 using 
the Startup Confidentiality Key. This process enables 
Brass Box 21 to implement the Domain Brass Process 
for one domain. This process is repeated for all domains 
required for a particular Brass Box. 

Generation. Installation and Registration Process 

Referring now to Figs. 24-27, an overview of Key 
Management System 10 Domain Master Key Installa- 
tion Process is shown. No distinctions exist between the 
vendor and any postal Domain. Each operates in a sim- 
ilar independent manner. To successfully install a full set 
of Domain master keys to the digital meter 36, the set of 
operations are run for the vendor Domain and another 
set of operations are run for the selected postal Domain. 

Referring now to Figs. 24, 29 and 30, Domain Mas- 
ter Key Requests come from the Key Distribution Com- 
puter 30 during the manufacturing process 
manufacturing. At 300, the requests are sent with an 
identification number of Steel Box 32 from Key Distribu- 
tion Computer 30 to KMS Computer 24 in message MI0. 
KMS Computer 24 requests Key ID at 302 from Domain 
Archive 74 which then generates a unique Key ID for the 
Domain. At 304 Domain Archive 74 sends a Key ID 
Response to KMS Computer 24 in message MI0\ KMS 
Computer 24 records a local time for an audit trail and, 
at 306, sends information in a Generate Key message 
MM to Oak Box 20. Oak Box 20 checks the request to 
determine the validity of the Domain, the validity of the 
Steel Box ID for the Domain and il the Key ID is higher 
than the last one processed for this Domain. If any of 
the checks prove false, Oak Box 20 returns a fail mes- 
sage to KMS Computer 24. If the checks are true, Oak 
Box 24 generates a Domain Master Key and set of Test 
tokens. At 308, Oak Box 20 delivers a Domain Master 
Key Record to KMS Computer 24 in message MI2. At 
310 KMS Computer 24 forwards the Domain Master 
Key Record to Domain Archive 74 in message MI3. 
Domain Archive 74 stores the Domain Master Key 
Record in the database and a response is sent to KMS 
Computer 24 at 312. At 314, KMS Computer 24 for- 
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wands the response to Oak Box 20 which sends a Gen- 
erate Response message to KMS Computer 24 at 316. 
At 31 8, KMS Computer 24 sends the Install Key Record 
to Key Distribution Computer 30 in a Request Response 
message MI4. 

Referring now to Fig. 25, when a digital meter 36 is 
presented on the Manufacturing Line, the PSR compu- 
ter 34 requests an install domain key record from the 
key distribution computer 30 at 330. At 330. Key Distri- 
bution Computer 30 sends an install domain key record 
to the PSR Computer in message MI4' which is further 
sent to Steel Box 32 at 334. Steel Box 32 queries the 
digital meter 36 for information, then at 336 sends the 
Domain Master Key in message MI5 to digital meter 36. 
The digital meter installs and checks the key and return 
status to Steel Box 32 which queries the digital meter for 
a set of Meter Test tokens. At 338, the Meter Test tokens 
are returned in message MI6 to the Steel Box 32, which 
checks the Meter Test tokens against those received 
from Oak Box 20. Thus, Steel Box 32 checks that the 
Domain Master Key generated by Oak Box 24 is the 
same as the key installed in the digital meter 36. At 340, 
Steel box 32 forwards the installation status and infor- 
mation in message MI7 to the Key Management Com- 
puter 24 through the PSR computer and Key 
Distribution Computer 30. Key Management Computer 
24 retrieves a domain master key record from the 
domain archive, takes a local time stamp and at 342 for- 
wards information to Brass box 21 in message MI8. 
Brass Box 21 generates test tokens from the Domain 
Master Key record from the Domain Archive 74. These 
are compared with the Meter Test tokens. This checks 
that the Domain Master Key in the Domain Archive is 
the same as the key installed in the digital meter. If they 
check out, the Domain Master Key record is updated 
and forwarded in message MI9 to the Key Management 
Computer 24 at 344. The Key Management Computer 
24 forwards in message MI9 the Domain Master Key 
Record to Domain Archive 74 and if successful returns 
a response to the Brass Box 21 at 346. Brass Box 21 
checks response and returns a success or failure verifi- 
cation to KMS Computer 24 at 348 and to Key Distribu- 
tion Computer 30 in message MHO. 

Key registration consists of associating the country 
of registration, and the indicia number with the product 
code number and the key. The key is then stored in the 
country sub-domain of the install domain using a secret 
key that is specific to the country sub-domain. The 
essential feature is that the brass process that is spe- 
cific to that country sub-domain relies on the install 
domain to install keys securely and with integrity. Keys 
never transfer from one install domain to another. 

Referring now to Figs. 26 and 31 , when the digital 
meter is prepared for a specific Security Domain, the 
Indicia Serial Number and/or Product Code Number is 
entered into the digital meter in message MR1. The 
PSR computer 34 requests registration tokens from dig- 
ital meter 36 at 360. The digital meter generates two 
digital tokens and returns them the PSR computer at 



362. The PSR computer combines the tokens with other 
meter information and forwards the resulting record to 
the Key Management Computer 24 through the Key Dis- 
tribution Computer 30 at 364. At 366 Key Management 

5 System Computer 24 retrieves a domain master key 
record from the domain archive, takes a local time 
stamp and forwards information to Brass Box 21 in mes- 
sage MR2. Brass Box 21 generates registration tokens 
from the Domain Master Key record from the Domain 

jo Archive 74. These are compared with the Meter Regis- 
tration tokens. This checks that the Indicia Serial 
Number, Product Code Number and Manufacturing 
Sequence Number were correctly reported by the Dig- 
ital Meter. If they check out. the Domain Master Key 

is record is updated and forwarded to the KMS Computer 
24 at 368. Key Management System Computer 24 for- 
wards the domain master key record to Domain Archive 
74 in message MR3 and if successful returns a 
response to the Brass Box 21 at 370. Brass Box 21 

20 checks response and returns a success or failure verifi- 
cation in message MR4 to Key Management System 
Computer 24 at 372. 

Every domain has at least one sub-domain that is 
responsible for registering keys to indicia numbers and 

25 performing indicia verification within that sub-domain. 
The Earth domain in particular has several country sub- 
domains. It is possible for one country to have meters in 
a sub-domain of the Earth domain and meters in the 
unique sub-domain of its own postal domain. In the 

30 example shown in Fig. 32, Country 3 has both a unique 
postal domain and a postal sub-domain of the earth 
domain. However, Country A has only meters that have 
keys which are installed within that country's unique 
postal domain. 

35 Referring now to Fig. 27, if a digital meter is taken 
out of service, the information is recorded and sent to 
the KMS Computer 24. Key Management Computer 24 
retrieves a domain master key record from the domain 
archive, takes a local time stamp an forwards informa- 

40 tion to Brass box 21 at 380. The Domain Master Key 
record is updated and forwarded to the Key Manage- 
ment Computer 24 at 382. The key management com- 
puter forwards the domain master key record to the 
domain archive and if successful returns a response to 

45 the Brass Box 21 at 384. Brass Box 21 checks response 
and returns a success or failure verification to Key Man- 
agement Computer 24 at 386. 

Generation of Tokens 

50 

Each meter uses the Domain Master Key to gener- 
ate a temporal key, also referred to herein as a token 
key, For each domain, which is used to generate a token 
from mailpiece data. The Key Management System 
55 may distribute postal temporal keys to authorized postal 
verification sites having a Distributor Token Verification 
Box 44 (Fig. 1), also referred to herein as Tin Box. 
Postal temporal keys are used by Tin Box 44 for local 
verification of indicia. Under this arrangement, the Key 
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Management System provides a higher level of security 
because the Post can obtain local verification of indicia 
without distributing the Master Key database at multiple 
sites. 

Verification Process 

The following paragraphs provide an overview of 
Key Management System 10 Verif cation Process. 
There are no distinctions between the vendor and any 
postal Domain. Each operates in a similar manner, inde- 
pendently. To successfully verify both tokens, the set of 
operations are run for the vendor Domain and another 
set of operations are run for the selected postal Domain. 

Token Verification Requests come from a data cap- 
ture system 19 located at Mail Facility 18. The request 
contains an ASCII text representation of information 
printed on a physical mail piece. Referring now to Fig. 
28, at 400 the request is sent to a Key Management 
System Computer 24 located in the vendor or postal 
Data Centers. The Key Management System Computer 
24 inspects the Mail Piece Data check digits and makes 
corrections if necessary. Key Management Computer 
24 retrieves a domain master key record from the 
domain archive and forwards information to Brass box 
21 at 402. Brass Box 21 checks the request and verifies 
that the Domain Master Key is Active. Brass Box 21 
recalculates the selected domain's token using the 
Domain Master Key from the Domain Archive and the 
mail piece information. The calculated token is com- 
pared with the mail piece token to see if they match. A 
good/bad comparison result is sent to the KMS Compu- 
ter 24 at 404. A second example is shown in Fig. 28 to 
highlight that an additional verification is required to ver- 
ify the other domain token. 

The foregoing description of the present invention is 
the preferred embodiment wherein the Post has author- 
ized a Vendor to generate Postal Master Keys and 
install them into digital meters. The keys are then sent to 
Postal Data Center 16 to be used for postal token vali- 
dation. The Key Management System includes the 
capability for different distribution of functionality, secure 
boxes and databases. For example, in one alternate 
embodiment, a Post authorizes the Vendor or another 
party to maintain and operate the Postal Data Center 
16, including the functions of postal key generation, 
maintenance, token validation and communicating keys 
to vendors. In this embodiment, the Postal Brass Box 40 
and the Postal Key Archive 42 are physically located at 
the site of the Vendor or other party. In another embod- 
iment, the Post manages its Data Center and the Postal 
Oak Box 22 is physically located at the Postal Data 
Center 16. 

In another alternate embodiment (not shown) any 
combination of the Key Management System functional- 
ity, i.e. domain oak process, domain steel process or 
domain brass process, could be integrated into any of 
the secure boxes. 



Thus, it will be understood that the Key Manage- 
ment System has an inherent flexibility that allows differ- 
ent domains, i.e., Posts, to implement different physical 
implementations of the same logical Key Management 
5 System. The Key Management System provides such 
flexibility while maintaining a high level of system integ- 
rity and security. It will be further understood that the 
present invention allows multiple vendors to support 
multiple posts. 

10 The present invention has been descrtoed for a pre- 
ferred embodiment relating to digital postage meter evi- 
dencing. It will be understood by those skilled in the art 
that the present invention is also suitable for use as a 
Key Management System for transaction evidencing in 

is general, such as for monetary transactions, item trans- 
actions and information transactions. 

As used herein, the term "digital postage meter" 
refers to conventional types of digital postage meters 
that are coupled to secured printing means and other 

20 types of digital postage meters that are coupled to unse- 
cured printing means or have other configuration differ- 
ences from such conventional digital postage meters. 

While the present invention has been disclosed and 
described with reference to a single embodiment 

25 thereof, it will be apparent as noted above that varia- 
tions and modifications may be made therein. It is, thus, 
intended in the following claims to cover each variation 
and modification that falls within the true spirit and 
scope of the present invention. 

30 

Claims 

1. A method of token verification in a Key Manage- 
ment System, comprising the steps of: 
35 providing to a transaction evidencing device 

a master key created in a logical security domain 
and a logical device identifier; 

creating a master key record in a key verifi- 
cation box; 

40 securely storing the master key record in a 

Key Management System archive; 

producing in the transaction evidencing 
device evidence in the logical security domain of 
transaction information integrity; 
45 inputting the evidence of the transaction 

information integrity to a token verification box; 

inputting in the token verification box the 
master key record from the Key Management Sys- 
tem archive; 

so determining in the token verification box that 

the master key is valid in logical security domain; 

using in the token verification box the master 
key to verify the evidence of transaction information 
integrity; and 

55 outputting from the token verification box an 

indication of the result of the verification of the evi- 
dence of transaction information integrity. 
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2. The method of claim 1 wherein the master key 
record includes the logical device identifier, the 
master key and a digital signature associating the 
logical device identifier and the master key. 

5 

3. The method of claim 1 or 2 wherein the step of 
determining in the token verification box that the 8. 
master key is valid in logical security domain corn- 
prises the step of: 

checking the digital signature to verify the w 
association of the logical device identifier and the 
master key within the logical security domain. 

4. The method of any preceding claim wherein the the 
transaction evidencing device is a digital postage 15 
meter 

5. A method of token verification in a Key Manage- 
ment System, comprising the steps of: 

providing to a transaction evidencing device 20 
a master key created in a logical security domain 
and a logical device identifier; 

creating a master key record in a key verifi- 
cation box; 

securely storing the master key record in a 25 
Key Management System archive; 

creating a temporal token key record using 
the master key in a token key distribution box; 

securely storing the token key record in a 
Key Management System archive; 30 

producing in the transaction evidencing 
device the token key; 

producing in the transaction evidencing 
device evidence in the logical security domain of 
transaction information integrity using the token 35 
key; 

inputting the evidence of the transaction 
information integrity to a distributed token verifica- 
tion box; 

inputting in the distributed token verification 40 
box the token key record from the Key Management 
System archive; 

determining in the distributed token verifica- 
tion box that the token key is valid in logical security 
domain; 45 

using in the distributed token verification box 
the token key to verify the evidence of transaction 
information integrity; and 

outputting from the distributed token verifica- 
tion box an indication of the result of the verification so 
of the evidence of transaction information integrity. 

6. The method of claim 5 wherein the token key record 
includes the logical device identifier, the token key 
and a digital signature associating the logical 55 
device identifier and the token key. 

7. The method of claim 5 or 6 wherein the step of 
determining in the distributed token verification box 



that the token key is valid in logical security domain 
comprises the step of: 

checking the digital signature to verify the 
association of the logical device identifier and the 
token key within the logical security domain. 

The method of any of claims 5 to 7 wherein the 
transaction evidencing device is a digital postage 
meter. 
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